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1.  Introduction 


The  U.S.  Army  Research  Laboratory’s  (ARL)  Battlespace  Decision  Support  Team  (BDST)  is 
exploring  methods  of  portraying  control  or  power  influence  in  the  battlespace.  Commanders 
receive  large  amounts  of  information,  and  a  quick  visualization  of  areas  of  control  would  provide 
the  Commander  another  tool  for  mission  planning  and  execution  monitoring.  This  display  would 
allow  the  Commander  to  assess  the  effectiveness  and  progression  of  his/her  forces. 

BDST  began  the  Battlespace  Terrain  Ownership  (BTO)  project  with  two  objectives  in  mind. 

The  first  is  that  the  system  would  enhance  the  course  of  action  development  process.  A 
Commander  or  his/her  staff  would  be  able  to  develop  a  scenario  in  One  Semi-Automated  Forces 
(OneSAF)  Testbed  Baseline  (OTB),  and  then  watch  the  proposed  scenario  play  out.  This  would 
allow  the  Commander  to  view  possible  outcomes,  and  if  necessary  adjust  the  scenario  and  then 
replay  the  mission.  Another  possible  use  for  BTO  would  be  during  mission  execution:  as 
information  is  received  from  intelligence  reports  and  battlefield  sensors,  the  control  picture 
would  be  updated.  The  Commander  would  have  an  up-to-date  picture  of  the  areas  under  control 
by  force. 


2.  BTO  Overview 


The  BTO  project  combines  three  components  to  provide  a  graphical  display  of  areas  of  influence 
in  the  battlespace.  The  first  component  is  the  combat  simulation;  the  second  component  is  the 
data  translation  process;  and  the  final  component  is  the  control  algorithm  and  associated  display. 
The  first  step  is  to  create  a  combat  scenario  in  OTB  v2.0.  OTB  provides  data  on  all  entities  in 
the  battlespace  and  direct-  and  indirect-fire  events.  The  second  step  converts  the  data  into  a 
format  for  the  control  algorithm.  The  final  process  invokes  the  control  algorithm  to  interpret 
different  factors  in  the  battlespace  and  provides  a  visual  display  of  control.  This  report  addresses 
the  second  step,  the  data  translation. 

To  provide  data  from  the  simulation  to  BTO,  we  modified  OTB.  The  first  step  was  to  enable 
information  to  be  collected  for  all  entities  in  the  battlespace.  We  modified  the  source  code  to 
print  out  logistical  information  from  OTB  regarding  identifying  information,  entity  status, 
location,  and  fuel  and  ammunition  supply  for  all  entities.  This  infonnation  is  written  to  a  file 
with  a  unique  timestamp  when  an  update  routine  is  called  in  OTB. 1  The  code  changes  also 
provide  a  quick  look-up  table  of  all  battlespace  entities.  The  next  step  was  to  obtain  information 


1  Heilman,  E.  G.;  O’May,  J.  F.  A  OneSAF  Data  Collection  Methodology  for  Experimentation',  ARL-TR-2663;U.S.  Army 
Research  Laboratory:  Aberdeen  Proving  Ground,  MD,  February  2002. 
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on  all  direct-fire  events.  Again,  we  modified  the  OTB  source  code  to  provide  information  as  to 
shooter,  target,  shooter  and  target  locations,  ammunition  used  (round),  dispersion  of  hit,  and 
outcome.  This  information  is  written  to  a  separate  file  and  each  event  has  an  associated  unique 
timestamp.2  We  originally  modified  OTB  vl.O  to  allow  entity  data  collection  and  direct-fire 
reporting.  When  the  U.S.  Army  Program  Executive  Office  for  Simulation,  Training,  and 
Instrumentation  (PEO  STRI)  issued  a  call  for  OTB  enhancements,  BDST  forwarded  their  code 
changes.  PEO  STRI  approved  the  changes  and  incorporated  them  into  OTB  v2.0. 

After  the  release  of  OTB  v2.0,  we  made  additional  changes  to  the  OTB  source  code.  One  change 
was  to  increase  the  functionality  of  the  data  collection  methodology.  The  original  changes 
allowed  data  to  be  collected  whenever  a  certain  OTB  function  call  was  made.  We  wanted  to  be 
able  to  control  the  timing  of  the  data-collection  process.  We  made  a  change  that  allowed  data 
collection  at  a  user-defined  interval.  By  a  file  read  at  OTB  initialization,  a  user  can  specify  an 
increment  in  seconds  and  OTB  will  collect  data  on  all  battlespace  entities  at  the  specified  time. 

If  no  time  is  entered,  the  system  defaults  to  a  1  min  collection  interval. 

A  second  change  made  to  OTB  was  to  collect  data  for  all  indirect-fire  events.  When  an  indirect 
fire  occurs,  data  is  collected  on  the  shooter  (if  available),  possible  targets,  type  of  ammunition, 
locations  of  the  shooter  and  targets,  and  outcome.  A  unique  timestamp  is  provided  for  each 
indirect-fire  event.  This  information  is  also  written  to  a  separate  file  for  parsing  by  the  BTO  data 
translation  process.3 

In  total,  OTB  creates  four  distinct  files  for  each  simulation  execution.  At  startup,  OTB  creates  a 
timestamp  variable.  This  unique  variable,  “arl  time,”  is  available  as  the  foundation  for  all  files 
created.  The  four  files  are:  “<arl_time>dc”  that  contains  information  on  all  battlefield  entities; 
“<arl_time>vf  ’  is  the  lookup  table  for  all  entities;  “<arl_time>df  ’  contains  infonnation  on  all 
direct-fire  events;  and  “<arl_time>if  ’  has  all  indirect-fire  events. 

The  second  component  of  BTO  is  the  actual  data  translation  for  inclusion  into  the  BTO 
algorithm.  The  data-translation  component  is  discussed  in  section  3  of  this  report.  The  third 
component  is  the  BTO  algorithm  and  graphical  display.  The  software  dynamically  computes 
power  projection  as  a  function  of  entity  location,  weapon  system  effectiveness,  combat  damage, 
and  probabilities  of  hit  and  kill. 

BTO  currently  displays  power  for  seven  different  categories  for  two  sides.  As  shown  in  figure  1, 
the  darkest  colors  (red  and  blue)  are  where  the  respective  sides  have  greater  than  6: 1  power.  The 
medium  colors  are  where  the  sides  have  greater  than  3:1  but  less  than  6: 1  influence.  The  lightest 


2 

“Heilman,  E.  G.;  O’May,  J.  F.  One  Semi-Automated  Forces  (OneSAF)  Killer/Victim  Scoreboard  (KVS)  Capability ;  ARL-TR- 
2829;  U.S.  Army  Research  Laboratory:  Aberdeen  Proving  Ground,  MD,  September  2002. 

3 

O’May,  J.  F.  Enhancements  to  OneSAF  Killer/Victim  Scoreboard  Capabilities',  ARL-TR-3758;  U.S.  Army  Research 
Laboratory:  Aberdeen  Proving  Ground,  MD,  April  2006. 
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colors  are  where  control  is  greater  that  1 : 1  but  less  than  3:1.  The  white  colors  represent  where 
neither  side  has  influence  due  to  weapon  range  restrictions.  Figure  2  is  the  same  control 
representation  placed  on  three-dimensional  terrain. 


Figure  1.  Two-dimensional  representation. 


Figure  2.  Three-dimensional  representation. 


3.  Software  Overview 


The  data  translation  software  selectively  converts  the  data  created  by  OTB  to  a  format  required 
by  BTO  for  control  determination  and  display.  OTB  is  capable  of  creating  large  amounts  of 
data.  The  amount  of  data  is  dependent  on  the  number  of  entities  present  in  the  scenario,  the 
amount  of  indirect-  and  direct-fire  events,  and  the  user-defined  period  for  data  collection.  A 
large  scenario  with  many  entities,  frequent  firings,  and  data  collection  points  would  provide  a 
voluminous  amount  of  data.  The  data  translation  software  must  parse  this  data  quickly  and 
provide  it  in  a  concise  format  for  immediate  inclusion  into  the  BTO  algorithm. 

As  previously  mentioned,  OTB  is  creating  four  separate  files  that  the  data-translation  process 
must  track.  The  first  file  is  the  “<arl  time>dc”  file.  This  file  contains  information  on  all  entities 
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and  their  aggregation  at  the  user-specified  or  default  data  collection  time  increment.  For 
example,  if  a  platoon  of  M1A1  tanks  is  in  the  scenario,  infonnation  will  be  available  on  all  four 
tanks  plus  a  roll-up  of  the  platoon.  A  timestamp  is  written  to  the  file  at  the  beginning  of  each 
time  period  for  data  collection.  For  each  entity  and  associate  aggregate,  OTB  provides  the 
following  information:  vehicle  marking;  vehicle;  unique  vehicle  identification  number 
(VTAB  ID);  location;  status  of  entity;  type  and  quantity  of  ammunition  on  board;  quantity  of 
fuel;  and  awareness  of  other  entities.  See  table  1  for  an  example  of  the  information  for  a  platoon 
(aggregated)  and  a  single  entity. 

Tablet.  Data  from  “<arl  time>dc”  file. 


Current  Count  1  at  Time:  1159281943 

MARKING:  100A3 

VEHICLE:  Ml  Platoon 

VTAB:  1042 

X  =  21929.55  Y  =  36048.95  Z  =  1154.80  CELL 

=  0 

Vehicle  Authorized/Undamaged/Catastrophic/Firepower/Mobility 

Damage  Damage  Damage 

Ml  4  4 

0 

0  0 

Equip/Supplies: 

Current  Lvl/Resupply  Lvl/Avg  Per  Veh 

Fuel  (Fuel)  (gallons) 

1475.05 

1600.00  350.00 

1 05mm  HEAT-T  (M456A1) 

60.00 

60.00  15.00 

1 05mm  SABOT  APDS-T  (M392A2) 

100.00 

100.00  25.00 

7.62mm  MG  (M240) 

10000.00 

10000.00  2500.00 

.50  Cal  MG  (M3 3) 

2400.00 

2400.00  600.00 

66mm  OPTICAL  SMK  (L8A1) 

80.00 

80.00  20.00 

Not  aware  of  any  vehicles. 

MARKING:  100A33 

VEHICLE:  vehicle  US  Ml 

VTAB:  1023 

X  =  21936.00  Y  =  36198.80  Z  =  1156.93  CELL 

=  0 

Vehicle  Authorized/Undamaged/Catastrophic/Firepower/Mobility 

Damage  Damage  Damage 

Ml  11  00 

0 

Equip/Supplies: 

Current  Lvl/Resupply  Lvl/Avg  Per  Veh 

Fuel  (Fuel)  (gallons) 

368.75 

400.00  350.00 

105mm  HEAT-T  (M456A1) 

15.00 

15.00  15.00 

1 05mm  SABOT  APDS-T  (M392A2) 

25.00 

25.00  25.00 

7.62mm  MG  (M240) 

2500.00 

2500.00  2500.00 

.50  Cal  MG  (M33) 

600.00 

600.00  600.00 

66mm  OPTICAL  SMK  (L8A1) 

20.00 

20.00  20.00 

Not  aware  of  any  vehicles. 
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The  second  file  created  provides  a  list  of  all  entities  in  the  simulation  named  “<arl_time>vt.” 
This  file  contains  a  unique  4-digit  identifier  for  each  entity,  the  entity  call  sign,  and  the  entity 
type.  This  file  also  acts  as  a  quick  look-up  table  for  entity  information.  See  table  2  for  an 
example  of  the  “<arl_time>vt”  file. 

Table  2.  Sample  data  from  “<arl_time>vt  file.” 


VTAB 

ID 

1013 

PO 

VEHICLE 

100B51 

VEHICLE 

TYPE 

vehicle 

USSR 

BMP2 

VTAB 

ID 

1006 

PO 

VEHICLE 

100B52 

VEHICLE 

TYPE 

vehicle 

USSR 

BMP2 

VTAB 

ID 

1031 

PO 

VEHICLE 

100B22 

VEHICLE 

TYPE 

vehicle 

USSR 

T72M 

VTAB 

ID 

1025 

PO~ 

VEHICLE 

100B21 

VEHICLE 

TYPE 

vehicle 

_USSR_ 

T72M 

VTAB 

ID 

1039 

PO~ 

VEHICLE 

100A71 

VEHICLE 

TYPE 

vehicle 

USSR 

T80 

VTAB 

ID 

1038 

PO 

VEHICLE 

100A61 

VEHICLE 

TYPE 

vehicle 

_USSR_ 

CO 

o 

VTAB 

ID 

1026 

PO 

VEHICLE 

100A41 

VEHICLE 

TYPE 

vehicle 

US  Ml 

VTAB 

ID 

1023 

PO 

VEHICLE 

100A33 

VEHICLE 

TYPE 

vehicle 

US  Ml 

The  final  two  files  store  information  on  fire  events.  The  third  file,  “<arl_time>df,”  contains  a 
listing  of  all  direct-fire  events.  This  file  contains  information  on  the  timestamp  of  the  direct-fire 
event,  firer  and  target  unique  identification  number  (VTAB  ID)  and  location,  type  of 
ammunition  used,  angle  of  impact,  range,  dispersion,  and  result.  See  table  3  for  sample  data. 

Table  3.  Two  sample  direct-fire  records  from  “<arl_time>df.” 


Time  Stamp  1159281988 
Firer  ID  1022 
Target  ID  1013 

Firer  Position:  X  =  21742.56  Y  =  36001.78  Z  =  1131.23 
Target  Position:  X  =  19157.00  Y  =  35316.30  Z  =  961.80 
Vehicle  1013:  Hit  with  1  "munition  US  M456A1"  (0x48bb0421) 
Comp  DFDAM_EXPOSURE_TURRET,  angle  0.73  deg  Disp  4.462900 
ft 

Kill  Thermometer  is:  Pk:  1.00,  Pmf :  0.60,  Pf :  0.20,  Pm: 
0.20  Pn:  0.20 

r  =  0.395290  kill  type  =  MF 
RANGE  1480.241770 


Time  Stamp  1159282020 
Firer  ID  1007 
Target  ID  1002 

Firer  Position:  X  =  3969.41  Y  =  44604.75  Z  =  1088.75 
Target  Position:  X  =  3994.02  Y  =  42597.80  Z  =  1117.77 
Vehicle  1002:  Hit  with  1  "munition  US  M392A2"  (0x48b80421) 
Comp  DFDAM_EXPOSURE_TURRET,  angle  -25.09  deg  Disp  2.316786 
ft 

Kill  Thermometer  is:  Pk:  1.00,  Pmf:  0.40,  Pf :  0.30,  Pm: 
0.20  Pn:  0.20 

r  =  0.990576  kill  type  =  K 
RANGE  1507.306901 
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The  final  file,  “<arl_time>if,”  contains  infonnation  on  every  indirect-fire  event.  Each  record 
contains  a  timestamp,  target  entity  identification  and  location,  ammunition  used,  shooter  identity 
and  location  (if  known),  location  of  impact,  and  result.  For  each  event  there  may  be  multiple 
records,  so  the  timestamp  will  identify  which  events  occurred  together.  A  record  is  written  for 
every  entity  that  must  assess  damage  when  an  event  occurs.  For  example,  in  table  4,  the  first 
three  records  are  for  the  same  indirect-fire  event  as  the  last  two. 

Table  4.  Sample  data  from  “<arl_time>if.” 


Time  Stamp  1159281995 

Vehicle  1005  assessing  IF  damage  with  1  "munition  US  M712" 
Entity  Location  X  =  6704.96  Y  =  43527.90  Z  =  1001.91 
Shooter  ID  0 

Shooter  Location  X  =  0.00  Y  =  0.00  Z  =  0.00 
U  No  Damage 

Detonation  Location  X  =  6875.25  Y  =  43639.78  Z  =  1004.41 


Time  Stamp  1159281995 

Vehicle  1017  assessing  IF  damage  with  1  "munition  US  M712" 
Entity  Location  X  =  6871.36  Y  =  43638.90  Z  =  1004.30 
Shooter  ID  0 

Shooter  Location  X  =  0.00  Y  =  0.00  Z  =  0.00 
F  Fire  Kill 

Detonation  Location  X  =  6875.25  Y  =  43639.78  Z  =  1004.41 


Time  Stamp  1159281995 

Vehicle  1004  assessing  IF  damage  with  1  "munition  US_M712" 
Entity  Location  X  =  6732.69  Y  =  43666.60  Z  =  1007.98 
Shooter  ID  0 

Shooter  Location  X  =  0.00  Y  =  0.00  Z  =  0.00 
U  No  Damage 

Detonation  Location  X  =  6875.25  Y  =  43639.78  Z  =  1004.41 


Time  Stamp  1159282284 

Vehicle  1031  assessing  IF  damage  with  1  "munition  US  M712" 
Entity  Location  X  =  7706.91  Y  =  39386.50  Z  =  976.84 
Shooter  ID  0 

Shooter  Location  X  =  0.00  Y  =  0.00  Z  =  0.00 
M  Mobility  Kill 

Detonation  Location  X  =  7705.84  Y  =  39386.56  Z  =  976.86 


Time  Stamp  1159282284 

Vehicle  1025  assessing  IF  damage  with  1  "munition  US_M712" 
Entity  Location  X  =  7734.64  Y  =  39525.20  Z  =  974.92 
Shooter  ID  0 

Shooter  Location  X  =  0.00  Y  =  0.00  Z  =  0.00 
U  No  Damage 

Detonation  Location  X  =  7705.84  Y  =  39386.56  Z  =  976.86 
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The  data  translation  program  continually  examines  all  four  files  as  OTB  creates  them, 
synchronizes  and  fonnats  the  data  from  the  files,  and  passes  the  data  onto  BTO.  The  main  class 
for  data  translation,  OneSAF.java,  handles  this  process.  All  four  files  previously  mentioned  are 
created  simultaneously  from  different  routines  inside  OTB,  so  the  data  translation  software  must 
constantly  poll  all  files  and  grab  any  new  data.  For  data  received  from  <arl  file>dc,  the  software 
only  puts  out  new  infonnation.  If  the  most  recent  timestamp  shows  the  same  information  for  all 
entities  as  the  prior  timestamp,  no  new  information  is  passed  to  BTO. 

The  OneSAF.java  class  interfaces  with  additional  classes  that  interrogate  the  four  files  created  by 
OTB.  Each  class  is  declared  as  an  array  of  objects:  Vector<DF_Object>,  Vector<IF_Object>, 
Vector<DC_Object>,  and  Vector<VT_Object>,  respectively.  In  addition, 
Vector<StdName_Object>  and  Vector<PositionRecord_Object>  are  defined  to  support 
translation.  “Reading”  classes  (ReadingDF,  ReadingIF,  ReadingDC,  ReadingVT,  and 
ReadingStdName)  are  designed  to  store  relevant  information  in  these  Java  objects  using  private 
helping  methods.  Each  of  these  classes  has  “get”  and  “set”  methods,  typical  of  object-oriented 
programming  when  working  with  the  representation  of  a  class,  for  accessing  private  member 
data. 

The  data-translation  software  creates  three  files  that  provide  the  required  data  to  the  BTO 
algorithm.  The  software  parses  the  data  from  these  four  files  into  a  format  readable  by  the  BTO 
algorithm  and  visualization  software  and  writes  the  new  data  in  timestamp  order.  These  three 
files  are  numbered  chronologically.  The  first  type  of  file  created  is  called  a  position  record,  as 
seen  in  table  5.  A  position  record  will  have  a  1  in  the  first  position  of  the  first  line.  The  first  line 
also  states  the  file  number  and  the  number  of  entities  currently  in  the  battlespace.  In  the  example 
shown  in  table  5,  this  file  contains  information  for  39  entities  and  is  the  ninth  file  written  by  the 
data  translation  software.  The  second  line  contains  the  timestamp  of  when  the  data  was 
collected.  The  next  lines  present  data  on  the  entities.  As  there  are  39  entities  in  the  battlespace, 
there  will  be  39  additional  lines,  one  for  each  entity.  For  each  entity,  the  following  information 
is  provided:  call  sign;  unique  identifier  (VTABID);  X,  Y,  and  Z  location;  and  current  health. 
The  health  is  presented  as  an  N  for  undamaged,  F  for  firepower  kill,  M  for  mobility  kill,  MF  for 
mobility  and  firepower  kill,  or  a  K  for  a  catastrophic  kill. 

The  second  type  of  record  written  is  a  direct-fire  record.  This  record  will  have  a  2  in  the  first 
position  of  the  first  line.  Also  on  the  first  line  is  the  number  of  the  file.  In  the  example  shown  in 
table  6,  this  direct  fire  record  was  the  tenth  file  written.  The  second  line  has  the  following 
information:  the  timestamp  from  the  fire  event;  the  unique  identified  of  the  target;  the 
identification  of  the  firer;  the  X,  Y  and  Z  of  the  target;  the  X,  Y  and  Z  of  the  shooter;  and  the 
result  of  the  fire  event.  In  the  sample  shown  in  table  6,  the  target  with  the  VTAB  ID  of  1001 
located  at  X=3966,  Y=42459,  and  Z=1 149  was  catastrophically  killed  by  the  entity  with  a 
VTAB  ID  of  1012  at  location  X=4040,  Y=44793,  and  Z=1095. 
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Table  5.  Example  of  a  position  record. 


1  (9)  -  39  entities 


1150734291 

100A71 

1039 

15082 

100A61 

1038 

10090 

100A62 

1037 

10006 

100B43 

1036 

19825 

100A63 

1035 

11090 

100B42 

1034 

19784 

100B12 

1033 

16990 

100B13 

1032 

17086 

100B22 

1031 

7707 

100B11 

1030 

16983 

100B41 

1029 

19690 

100B02 

1028 

8241 

100A81 

1027 

4528 

100A41 

1026 

22057 

100B21 

1025 

7735 

100B03 

1024 

8408 

100A33 

1023 

21936 

100A32 

1022 

21927 

100A31 

1021 

21832 

100A34 

1020 

22023 

100A82 

1019 

4501 

100A92 

1018 

6571 

100B33 

1017 

6871 

100A13 

1016 

3419 

100A93 

1015 

6738 

100A91 

1014 

6599 

100B51 

1013 

19157 

100A14 

1012 

3672 

100A12 

1011 

3609 

100A2  4 

1010 

6010 

100A23 

1009 

5757 

100A22 

1008 

5947 

100A11 

1007 

3546 

100B52 

1006 

19029 

100B32 

1005 

6705 

100B31 

1004 

6733 

100A21 

1003 

5884 

100A51 

1002 

3994 

100A52 

1001 

3966 

36317 

963 

N 

36745 

940 

N 

36515 

938 

N 

36853 

996 

K 

36402 

945 

N 

36988 

994 

N 

36821 

941 

N 

36718 

938 

N 

39387 

977 

N 

36622 

936 

N 

36812 

989 

MF 

42192 

945 

N 

40193 

1042 

N 

36053 

1171 

N 

39525 

975 

N 

42303 

942 

N 

36199 

1157 

N 

35999 

1154 

N 

36103 

1144 

N 

35895 

1164 

N 

40055 

1041 

N 

41190 

991 

N 

43639 

1004 

N 

44850 

1112 

N 

41301 

987 

F 

41329 

991 

N 

35316 

962 

N 

45039 

1118 

N 

44913 

1108 

N 

45440 

1195 

N 

45250 

1138 

N 

45314 

1180 

M 

44786 

1103 

M 

35376 

959 

N 

43528 

1002 

N 

43667 

1008 

N 

45187 

1144 

N 

42598 

1118 

N 

42459 

1149 

N 

Table  6.  Example  of  a  direct-fire  record. 


2  (10) 

1150734397  1001  1012  3966  42459  1149  4040  44793  1095  K 
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The  last  record  created  by  the  data  translation  software  is  an  indirect-fire  event.  This  record  will 
have  a  3  in  the  first  position  of  the  first  line.  In  the  sample  shown  in  table  7,  this  record  is  the 
16th  record  written.  The  information  provided  is:  timestamp  of  the  indirect- fire  event;  unique 
identifier  of  the  target;  unique  identifier  of  the  shooter  if  available;  X,  Y,  and  Z  location  of  the 
target;  X,  Y,  and  Z  location  of  the  shooter  if  available;  and  result  of  the  indirect-fire  event.  In  the 
example  in  table  6,  target  1009  located  at  X=6381,  Y=43498,  and  Z=1007,  received  a  firepower 
kill  as  a  result  of  the  indirect-fire  event.  In  this  example,  there  is  no  information  on  the  shooter 
which  would  indicate  damage  from  possibly  a  mine. 


Table  7.  Example  of  an  indirect-fire  record. 


3  (16) 

1150734689  1009  0 

6381  43498 

1007 

0 

0 

0 

F 

We  developed  the  data-translation  software  using  Java  2  version  5.0  (J2v5.0).  The  translation 
application  is  synchronized  with  the  other  two  BTO  (OTB  and  the  BTO  algorithm  and 
visualization  software)  components  to  eliminate  any  user  intervention.  One  reason  we  selected 
J2v5.0  for  implementation  was  the  large  number  of  thread-related  classes  to  maximize 
processing  capability.  This  in  combination  with  application  of  asynchronous  JavaScript  and 
XML(Ajax)  technology  in  a  Web  2.0  environment  during  display  should  allow  for  a  near  real¬ 
time  BTO. 


4.  Conclusion 


The  data-translation  software  developed  at  ARL  provides  a  means  to  interrogate  and  parse  large 
amounts  of  data  to  feed  the  BTO  algorithm  and  visualization  software.  While  the  system 
currently  uses  data  from  a  combat  simulation,  the  algorithm  can  be  adapted  to  incorporate  real¬ 
time  battle  information  from  sources  such  as  Blue  Force  Tracker,  intelligence  gatherers,  and 
sensors.  The  display  provides  a  quick  overview  to  a  Commander  on  areas  controlled  by  forces. 
BTO  would  provide  a  technique  for  quick  assessment  of  force  progression  for  the  Commander  of 
the  future  and  a  methodology  for  real-time  visualization  of  control  of  the  battlespace. 
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List  of  Symbols,  Abbreviations,  and  Acronyms 


ARL 

BDST 

BTO 

OneSAF 

OTB 

PEO  STRI 


U.S.  Army  Research  Laboratory 
Battlespace  Decision  Support  Team 
Battlespace  Terrain  Ownership 
One  Semi-Automated  Forces 
OneSAF  Testbed  Baseline 

Program  Executive  Office  for  Simulation,  Training,  and  Instrumentation 
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NO.  OF 

COPIES  ORGANIZATION 


1  DEFENSE  TECHNICAL 
(PDF  INFORMATION  CTR 
ONLY)  DTICOCA 

8725  JOHN  J  KINGMAN  RD 
STE  0944 

FORT  BELVOIR  VA  22060-6218 

1  US  ARMY  RSRCH  DEV  & 
ENGRG  CMD 
SYSTEMS  OF  SYSTEMS 
INTEGRATION 
AMSRD  SS  T 
6000  6TH  ST  STE  100 
FORT  BELVOIR  VA  22060-5608 

1  DIRECTOR 

US  ARMY  RESEARCH  LAB 
IMNE  ALC  IMS 
2800  POWDER  MILL  RD 
ADELPHI  MD  20783-1197 

3  DIRECTOR 

US  ARMY  RESEARCH  LAB 
AMSRD  ARL  Cl  OK  TL 
2800  POWDER  MILL  RD 
ADELPHI  MD  20783-1197 


ABERDEEN  PROVING  GROUND 
1  DIR  USARL 

AMSRD  ARL  Cl  OK  TP  (BLDG  4600) 
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NO.  OF 

COPIES  ORGANIZATION 


10  DIRUSARL 

AMSRD  ARL  Cl  CT 
CHIEF 

J  OMAY  (4  CPS) 
A  NEIDERER 
RKASTE 
E  HEILMAN 
C  HANSEN 
AMSRD  ARL  Cl  C 
B  BROOME 
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